Various constraint types have been defined for database entities. In particular, data entities may be identified as either Type 1 or Type 2, wherein Type 1 data entities model items or objects in a way that precludes access constraints to information indicative of any changes to the modeled items or objects over time, and wherein Type 2 data entities model items or objects in a way that permits such access constraints to be enforced. For example, for agents of a contact center wherein each agent may be assigned to multiple agent groups concurrently, and may be assigned to or removed from various agent groups over time, data entities for modeling membership of agents in groups is typically modeled as Type 2 so that time-based constraints related to group membership are maintained. In particular, for each database group data entity that models a contact center group, such a typical time-based constraint would be: for each contact center group G, associate the entities in a contact center database so that from a group data entity modeling the group G, the only agent performance data available for access is the agent performance data for each time period that each agent was/is a member of the group G.
Although such Type 2 database schema constraints are generally appropriate and desired, there are circumstances when such constraints preclude easy implementation of certain operations such as simulations of groups. For example, to simulate the performance of a proposed agent group, access would be typically required to at least some (if not most) agent performance data for agents proposed to be members of the simulated group. However, such Type 2 database constraints as described above, prevents access to such historical agent performance data if the simulated group is modeled by a group data entity (and an associated membership data entity) which conforms to such Type 2 constraints. Accordingly, the alternative would be to implement an entire new schema for simulated groups. However, then such simulated groups could not be easily converted to actual groups without re-entering the group information. Moreover, extra effort would be required if it is desired to associate the simulated group information with the actual group so that, e.g., subsequent actual group performance can be compared to the simulated group performance.
Accordingly, it is desirable to have a method and database schema architecture that allows simulated groups as described hereinabove to be implemented with a database schema architecture together with operations that allow both Type 2 constraints for actual groups, and additionally allow simulated groups to be provided, wherein for members of a simulated group, substantially all agent performance data prior to the creation of the simulated group is available to be accessed via a data entity for the simulated group.